1. Field of the Invention
Embodiments of the present invention generally relate to computer graphics and, more specifically, to the serialization of function calls made to a graphics API for debugging a remote device.
2. Description of the Related Art
The term rendering refers to a process performed by computer software and hardware in generates images that portray an object or scene. For example, a hand-held video game system sequentially renders frames of animation for a video game. Typically, graphics hardware includes a graphics pipeline configured to generate frames by performing object, geometry, vertex, and raster operations on a set of graphics primitives designated for each frame. The graphics pipeline is often highly configurable. For example, the graphics pipeline may be configured with different shader programs, lighting constants, and texture maps, among other things. A hardware driver provides an interface between a particular piece of graphics hardware and the calls provided by a graphics API. Typically, a graphics application invokes calls provided by the graphics API in order to render elements of a 3D scene, the most common being a “draw” call passed the coordinates of a polygon (e.g., a triangle) to be rendered. Widely used graphics APIs include the OpenGL® API distributed by the Khronos group and the Direct3D® API distributed by Microsoft®.
A typical cycle for debugging the graphics application includes compiling and running the application. As the application is running, the developer looks for any anomalies or visual artifacts in frames rendered by the hardware and software. Visual artifacts may include elements of a frame that have an appearance other than what was intended by the developer, and non-visual anomalies includes poor performance of the graphics application, such as a low frame rendering rate. These issues may occur due to the application setting an incorrect render state, using a non-optimal or incorrect texture, or the use of incorrect parameters supplied to draw calls, among other things.
Application developers commonly perform simple experiments to diagnose and resolve these types of visual artifacts and performance issues. For example, the developer may experiment with the graphics application by tweaking program source code, adjusting a render state, or changing parameters of the graphics pipeline. The developer then runs the application to observe the result. Although this approach can be effective, it often becomes a cumbersome process. Further, when trying to diagnose and correct a problem on a certain target platforms such as an embedded or hand-held device (e.g., a hand-held video game console, a mobile phone, PDA, or convergence device), the debugging process may be even more complicated as the graphics application must be deployed to the target device.
To address the inefficiency resulting from a purely ad-hoc approach, graphical application debuggers are available. However, these applications typically execute on the same system as the graphics application. For graphics applications on handheld devices, this approach is impractical at best due to the screen size of these devices. For example, most of the handheld video game devices currently available include a screen resolution of 320×240 or 640×480 pixels. Thus, the screen displays may be too small to provide developers with a useful debugging interface. Further, the hand-held device may not have the processing power (or multi-tasking capability) required to run a graphical application debugger alongside a graphical application.
One approach to debugging an application for an embedded or handheld device is to debug the application remotely, for example, from a desktop personal computer. In such a case, a debugging tool should allow the developer to view the contents of the framebuffer on the remote device to help identify rendering bugs. For example, a debugging tool may be configured to capture the contents of a framebuffer on the remote device after a frame is rendered and transmit this information to the debugging tool running on a connected computer. However, this approach requires significant bandwidth and, thus, often reduces the interactivity of the debugging tool. For example, for a remote device with a 640×480 display, a bitmap image for a single frame includes data for 307,200 pixels. With frame rates for a hand-held video game device often reaching 18-24 frames per-second, or more, waiting for bitmap data to be transmitted for each frame may substantially diminish the usefulness of a debugging tool.
As the foregoing illustrates, there remains a need in the art for techniques to serialize function calls to a graphics API for debugging a remote device.